【AWS SAA対策 Udemy】AWS Well-Architected
AWS Well-Architected は、クラウドアーキテクトがアプリケーションやワークロード向けに高い安全性、性能、障害耐性、効率性を備えたインフラストラクチャを構築する際に役立ちます。AWS Well-Architected では、5 つの柱（優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化）に基づいて、お客様とパートナーがアーキテクチャを評価し、時間と共に拡大できる設計を実装するための一貫したアプローチを提供しています。
AWS Well-Architectedの基礎
AZの選択
1つのリージョンに2つのAZ利用する。3つ以上はコスト低下
AZにそれぞれEC2を配置して、サブネットでつなげていく。
EC2でDBをつなげて、S3にレプリケーションにバックアップする。
VPC
2つ以上のVPCでアーキテクチャを設計するのが基本となる。
AZ毎にVPCを分けて、開発環境、検証環境を用意する。
サブネット
パブリックサブネット、プライベートサブネットをそれぞれ作る
サブネットはCIDRで分割したネットワークセグメントになっている
サブネットはインターネットアクセス範囲を定義する為に利用する
WEBアクセスが必要かでプライベートか、サブネットか
VPC間接続の設計
VPC Pearingを使ってVPC間の接続を行う
Well-Architected Framework
Reliability
信頼性
Performance Efficiency
パフォーマンス効率
Security
安全性
Cost Optimaization
コスト最適化
Oparation Excellence
運用上の優秀性
Sustaninbillty
持続化可能性
Well-Architected Frameworkは3つの構成でなっている
(1)上記の5つの項目
(2)AWSのSAまたは、認定パートナーによる支援制度
(3)セルフチェックでのTools
あくまでも、ベストプラクティスを利用する事で最適解や改善点を把握できる。あくまでも参考であり絶対ではない。
信頼性の確保
インフラサービスの障害復旧化
耐障害性の向上
別リージョンや別AZにバックアップをとっておく。
スタンバイ構成をとることで継続的にサービスを動作させる
高可用性の確保
アーキテクチャにより、システムダウンが置きないようにする
AWSアーキテクチャにおいて、如何に高可用なシステムを実行するかが重要なポイントとなっている。
AWSはマルチAZ構成により高可用性を高める
具体的な高可用性の対応
単一障害点の排除→ELBによって切り替えができるようにする。
ELBを使ってマルチAZ、マルチVPCで運用をさせる
マルチAZでマスタースレーブ構成をとって、自動フェイルオーバを切り替え可能で、かつリードレプリカで負荷を軽減させる
他にもElastic IPを設定して、同じパブリックIPをもつ別のインスタンスにIPをフローティングする
ELB
マネージド型ロードバランシングサービスでEC2インスタンスの処理を分散する際に標準的に利用する
AutoScaling、Route53と連携する。
利用できるタイプ
Classic Load Balancer
初期に提供されたELBであり、標準的なL4/L7におけるロードバランシング
Appliction Load Balancer
レイヤー7の対応が強化された単一ロードバランサーで、異なるアプリケーションへリクエストをルーティングが可能
パスルーティングで複雑な設定が可能
Network Loaf Balancer
NLBは後スループットを維持しながら大量のリクエストを捌くように設計された新しいロードバランサーになっている
NLBはDockerなどを利用したコンテナ化されたアプリケーションをサポートしています。
負荷テストについて
NLBはPre-warming申請は必要ありません
スティッキーセッションはセッション中に、同じユーザから来たリクエストを全て、同じEC2インスタンスに送信する機能です。
Auto-Scaling
需要増加に伴いトラフィック量が処理できなくなる前に、処理サーバを拡張する事で対処する必要がある
Auto-Scalingは水平スケーリング
垂直スケーリングはメモリやCPUの増加を行う
Auto-Scalingグループ
スケールするインスタンスの最大/最小などを設定する
今時点で必要なインスタンス吸うの数量になるようにインスタンスの起動/停止を行う
ELBのターゲットグループを設定すれば、ELB構成を利用してELBのヘルスチェックによりAutoScalingを実行することができます。
Auto-Scaling configiuration起動設定
Auto-Scaling Plan
どのようにスケールするかの方法を定義する
動的スケーリングなど、トラフィックによって設定できる
これらの設定は複数組み合わせて最適なものをつくっていく
ヘルスチェック
Auto-Scaling配下のEC2のヘルスチェックにはEC2のステータスを利用する
ターミネーションポリシー
需要減に基づくスケールインの際にどのインスタンスから終了するかを設定
Auto-Scalingのターミネーションポリシーのデフォルト設定は
OldestLaunchConfigurationからClosestToNextInstanceHourの順番に適用していきます。
基本的な連携
ELB→Auto-Scaling
Cloud Watch→AutoScaling
RDS
Amazon Relational Database Service (Amazon RDS) を使用すると、クラウド上のリレーショナルデータベースのセットアップ、オペレーション、スケールが簡単になります。ハードウェアのプロビジョニング、データベースのセットアップ、パッチ適用、バックアップなどの時間がかかる管理タスクを自動化しながら、コスト効率とサイズ変更可能なキャパシティーを提供します。これにより、アプリケーションに集中することができ、必要とされる高速なパフォーマンス、高可用性、セキュリティ、互換性をアプリケーションに実装できるようになります。
様々なデータベースソフトウェアに対応したフルマネージドサービス
MySQLやPosgreSQLなどを使える
AWSにおけるデータベース構築はEC2に自らインストールして構築するか、専用DBサービスを利用するかの2通り
RDSでDB専用サーバーを用意できる。
大きなメリットとしては、構築・運用が楽になっている。
EC2の場合は自分でMySQLをインストールして運用する流れになっている。
デメリット
最新のバージョンが使えるとかはない。
キャパシティに上限がある。OSへのログインできない
RDS自体がマネージド型の高可用性を保っており、DBの読み取りを処理をスケールアウトができる。
AS同士で同期レプリケーション、自動フェイルオーバを設定できる
非同期でリードレプリカを設定できる
自動/手動でS3などにスナップショットを取得して保存管理し、耐障害性を確保できる。
RDSのスナップショットはリージョン内のS3に保存されます。
RDSすごい！！
スケーリング
RDSを使うと、データベースシャーディングを使ってRDSの書き込み処理をスケーリングする
データベースのパフォーマンス低下に対してスケーリングを行う事でパフォーマンスを向上させる
RDS 暗号化
保存時のインスタンスとスナップショットの暗号化が可能
AES-256で暗号化が可能
インスタンス作成時にのみ設定が可能
RDSのストレージ容量増加の変更はできるが減少ができない。
スケールアップを実行すると容量増加を自動で行える。
RDSのスケールアウト
リードレプリカの増設
最大5台
Auroraは15台可能
マルチAZやクロスリージョンとも併用可能
キャッシュ = Elastic Cacheを連携させる事で、キャッシュを増設し、読み込み処理の高速化を実施する。
Auroaへの移行
RDSのMySQLとPostgreはAuroaと互換性がるバージョンは容易に変更ができる。
DBインスタンスを選択できる
途中でインスタンスタイプを縮小するなど変更することが可能です。